Modeling languages may be used as meta-languages to describe and execute underlying processes, such as business processes. For example, process modeling languages allow an enterprise to describe tasks of a process, and to automate performance of those tasks in a desired order to achieve a desired result. For instance, the enterprise may implement a number of business software applications, and process modeling may allow coordination of functionalities of these applications, including communications (e.g., messages) between the applications, to achieve a desired result. Further, such process modeling generally relies on language that is common to, and/or interoperable with, many types of software applications and/or development platforms. As a result, for example, process modeling may be used to provide integration of business applications both within and across enterprise organizations.
Thus, such modeling languages allow a flow of activities to be graphically captured and executed, thereby enabling resources responsible for the activities to be coordinated efficiently and effectively. The flow of work in a process is captured through routing (e.g., control flow) constructs, which allow the tasks in the process to be arranged into the required execution order through sequencing, choices (e.g., decision points allowing alternative branches), parallelism (e.g., tasks running in different branches which execute concurrently), iteration (e.g., looping in branches) and synchronization (e.g., the coming together of different branches).
During execution of process models, errors and other exceptions may occur. For example, hardware or software malfunctions may occur. As another example, a user or system may have a certain expectation of a remote system (e.g., an expectation of an available memory or processing capability thereof), which may be at least temporarily incorrect, so that the remote system may not be able to perform a desired or expected functionality. Of course, human error also may occur during a design or execution of a process model.
When an error occurs at a particular task of a process model, the results may or may not affect subsequent tasks of the process model (e.g., may affect some subsequent tasks, but not all). Similarly, if the process model is in communications with other (remote) process models (e.g., to coordinate shipments of goods), the results may or may not affect the remote process models.
In some cases, within a particular, process model, an exception may be handled, for example, by “rolling back” or undoing the problematic task(s), or by executing a contingency for the problematic task(s). However, such solutions may be of little use if the process model is collaborating with remote process model(s) that, for example, execute based on an expectation of the process model (e.g., where a delivery truck is dispatched in expectation of an order being ready, or where an order is placed based on expectation of payment being received). Consequently, such exceptions should be managed in order to reduce or minimize an effect on associated, collaborating process models.